Which to choose EC2 Reserved Instances (RI) vs. Savings Plans (SP)?
*** This post is an English-translated version of the original Japanese post.
Hello/Konnichiwa, this is Chiba.
Both Reserved Instances (RI) and Savings Plans (SP) offer discounts by committing to use an instance for a set period of time.
There are some similarities between these two, but also some differences. You might be unsure which one to choose. To help you overview each requirement and find out which gives you the best cost-benefit, I have prepared a comparison table.
It includes only Amazon EC2, while RIs and SPs are compatible with several AWS services.
Key Elements
Before going through the comparisons, let’s review the key elements of each plan.
Key elements of RIs
The point to note is that RIs have the concept of scope and offering classes. Regarding the discounts, I marked high, middle, or low, which vary depending on the purchasing method.
Key elements of SPs
The number of attributes to specify is fewer than the case of RI. Instead of instance attributes, an hourly commitment amount is considered. Out of three available types of an SP, I exclude SageMaker SP here, as it cannot be applied to EC2.
RIs and SPs covered by this post
I will compare these six types in the comparison below.
RI vs. SP Comparison Table
Here is the comparison of RIs vs. SPs. Please click on the image and zoom in to see the details.
Please note:
- The commitment term (one year or three years) and the payment option (all upfront, partial upfront, or no upfront (monthly)) are excluded from the criteria in the table, since there is no significant difference between RIs and SPs.
- Items in blue marked with ✅ are beneficial over others.
- I grouped the results for ‘Savings over On-Demand’ into two types, high and low.
- Pricing of EC2 Instance SP is the same as Standard RI
- Pricing of Compute SP is the same as Convertible RI
I will also list other design versions of this table at the end of the post.
The Difference Between RIs and SPs
What is different between RIs and SPs? One clear difference is how you order at the time of purchase.
In both cases, you purchase the right to offset the on-demand costs of instances under the specific conditions, with lower pricing than on-demand.
To place an RI order, you need to determine different instance attributes. While there is a minor difference depending on the scope and the class, some attributes are to be specified in any case. The purchased plans could be wasted if you run an instance that does not meet the conditions such as platform, instance type, etc.
In the case of SPs, you should estimate your usage and commit to that amount. You set a rather rough index, although it may slightly differ depending on the plan types. SPs then apply the most beneficial rates for your instances automatically.
Pros and Cons
The advantage of an SP is flexibility of the applicable instances. As you can see ‘instance attributes’ of the comparison table, many attributes are ‘Not required’, which means they are not the eligibility criterion. An instance is still eligible for an SP even when you change its instance size midstream or its platform, such as Windows and Linux.
This flexibility is a great benefit if you want to change your infrastructure.
On the other hand, since you need to carefully estimate the commitment value of an SP before purchase, you require more effort for its calculation. You should also be aware that it is not easy to track which resources are the supposed targets of your SP discount, whereas RI’s target attributes can be easily seen in your order history on the console.
If your organization purchases an SP every year or every three years, you need to continuously document the detailed calculations for the case, even when a person in charge of that documentation may change within your organization. In other words, if these prerequisites are acceptable to your organization, SPs will be your natural choice and RIs won’t be your choice in most cases.
Comparison of RIs and SPs by Types
Let’s take a closer look at the differences by comparing each type.
Regional RI vs. Zonal RI
The difference is a scope of an RI. Pricing is the same for both. A remarkable point is that zonal RIs can reserve capacity.
When creating a new EC2 instance or starting the one in stopped state, an error may occur due to no On-Demand capacity available on the AWS side. You can avoid this error by capacity reservations.
Among RIs/SPs, only zonal RIs offer a capacity reservation. However, combining with On-Demand Capacity Reservations (ODCR) enables you to reserve capacity even if you have other types of plans.
Please note that zonal RIs do not support instance size flexibility. The discount will not be applied to your instance when you change its instance size during the term.
(The flexibility is not always applicable to regional RIs either. There are some conditions, such as an instance having shared tenancy or on a Linux platform. Please refer to the latest documentation above for the details.)
Standard RI vs. Convertible RI
The difference is an offering class of an RI. Standard RIs offer a higher discount rate and allow you to trade on Marketplace.
For both types, some instance attributes can be changed, such as below:
- Change AZ within the same region (in case of zonal RIs)
- Change between Regional and Zonal RIs
- Change instance size within the same instance family (Linux/UNIX only)
See below for more information.
Some attributes that cannot be ‘changed’ can be exchanged through replacement. Exchanges are only available on convertible RIs.
The point to be considered is that the value of an RI after replacement should be the same or greater than before exchange. If you replace instances with smaller instance sizes, it is necessary to increase the total values, such as increasing the quantity of the RI. If the prices of the RI after the exchange are more expensive, you should pay the difference.
There are a few more caveats, such as you cannot change a payment option from all/partial upfront to no upfront. See below for more details.
EC2 Instance SP vs. Compute SP
The difference is a type of an SP. Both types do not require so many instance attributes as RI.
Compute SPs offer a lower discount rate than EC2 Instance SPs, but do not require you to determine instance family or region. They are also compatible with the other AWS services such as Lambda and Fargate.
SPs are applied to your instances roughly in the following order of priority:
- If there is an RI that meets the same criteria, the RI is applied first.
- If an EC2 Instance SP and a Compute SP with the same conditions exist, the EC2 Instance SP takes precedence.
- If there are multiple instances that meet an SP, the target receiving the higher discount rate is prioritized.
Here is an example of the no. 3. This assumes that you have two instances and an SP with a 10 USD/hour commitment.
| Savings (Discount rate) | On-Demand rate | Commitment amount | |
|---|---|---|---|
| Instance A | 90.00 USD (90%) | 100.00 USD | 10 USD |
| Instance B | 2.50 USD (20%) | 12.50 USD | 10 USD |
You want to offset the on-demand fee for one of the instances against the commitment of 10 USD. In this case, the SP should be applied to the instance A, which has a higher discount rate. If it is applied to the instance B, you will lose a lot of money. Not only you get a smaller discount, but the full on-demand fee for instance A of 100 USD will be incurred as it is.
The gap in actual pricing rates cannot be this extreme, but I hope you can see the benefit of SPs automatically applying to the one with the higher discount rate. I find it very appealing that an SP is applied to the most efficient target, while there are many factors that can affect the discount rate, including platform and instance size.
For more information on the order of priority in SPs, please refer to the following links.
Again, the Comparison of RIs vs. SPs
Let’s take a look at the whole comparison table of all types again.
Below I give some additional information about the items that I have not mentioned yet.
Queueing a purchase
You cannot queue a purchase of a zonal RI, which offers a capacity reservation by default. Previously, SPs did not support queueing either, but it changed in September 2020.
Expiration Alerts
Expiration Alerts are convenient feature for the operation phase. It was not supported for SP until November 2020 but since then it has been supported.
Applying for a revised price
The price revision here refers to a reduction in On-Demand rates. Price cuts in On-Demand rates have been made several times in the past.
In the case of RIs, the pricing remains the same as at the time of purchase. It means subsequent On-Demand price revisions will result in a loss in the discounted rate.
For example, below is a hypothetical price revision:
| Before revision | After revision | |
|---|---|---|
| On-Demand | 20 USD | 18 USD |
| RI | 15 USD | 13 USD |
In this scenario, you purchased an RI for 15 USD before the On-Demand price went down. Regardless of the payment type (upfront/monthly), the 15 USD for the purchased RI remains the same after the price change.
The original discount was 5 USD while the discount reduced to 3 USD after the price revision, resulting in a relatively low discount rate. This is a loss for you, because the RI would have only costed 13 USD if you had purchased one after the price revision.
For Convertible RIs, you can exchange your RI with an RI of the new price rate. (In this case, 13 USD instead of 15 USD) However, due to the condition of the exchange, “the new instance should be of an equal or higher value than the original one”, you’re required, for example, to order an increased number of RI for adjustment.
In the case of SPs, On-Demand pricing hasn’t been revised since its service release. It is unclear whether the SP pricing will be changed along with the price reduction of On-Demand. At least, the price rates stay the same after purchase even if SP pricing changes. See below for more information.
Conclusion
Regarding this comparison of EC2 RIs and SPs, it may be confusing for you to determine which fits better for your use cases, because there are too many aspects to consider. In this blog, I have explained all the variables. I hope that this blog will help you make a decision.
Personally, I recommend you to consider SP first. Since its instance attributes can be flexible, SPs have a big advantage that you can avoid the unintentional situations where the plans are no longer supported due to unmatched attributes.
If you are interested in the features that only RIs can provide, not SPs, please consider first if you can make it happen with an alternative way. If not, then you should go on to use RIs after understanding its limitations.
Other Versions of the Table
Black and white
Data in CSV
Here is the data in a CSV format. You can paste it on the Spreadsheet and format the table as you like.
,,Savings Plans,,Regional RI,,Zonal RI, ,,EC2 Instanse SP,Compute SP,Standard,Convertible,Standard,Convertible Pricing,Savings over On-Demand,✔︎Relatively high (up to 72% off),Relatively low (up to 66% off),✔︎Relatively high (up to 72% off),Relatively low (up to 66% off),✔︎Relatively high (up to 72% off),Relatively low (up to 66% off) Instance attributes,Instance family,Required,✔︎Not required,Required,Required,Required,Required ,Instance size,✔︎Not required,✔︎Not required,Required but flexible,Required but flexible,Required,Required ,Region,Required,✔︎Not required,Required,Required,Required,Required ,AZ,✔︎Not required,✔︎Not required,✔︎Not required,✔︎Not required,Required,Required ,Platform,✔︎Not required,✔︎Not required,Required,Required,Required,Required ,Tenancy,✔︎Not required,✔︎Not required,Required,Required,Required,Required Features,Capacity reservations,ODCR is required,ODCR is required,ODCR is required,ODCR is required,✔︎Yes,✔︎Yes ,Selling/Buying on Marketplace,No,No,✔︎Yes,No,✔︎Yes,No ,Exchanging after a purchase,No,No,No,✔︎Yes,No,✔︎Yes ,Spplied to Lambda and Fargate,No,✔︎Yes,No,No,No,No Operation,Calculation of hourly commitment at purchase,Required,Required,✔︎Not required,✔︎Not required,✔︎Not required,✔︎Not required ,Modifying after a purchase,No,No,✔︎Available in some attributes,✔︎Available in some attributes,✔︎Available in some attributes,✔︎Available in some attributes ,Queuing a purchase,✔︎Yes,✔︎Yes,✔︎Yes,✔︎Yes,No,No ,Applying for a revised price,No,No,No,✔︎Available by exchanging,No,✔︎Available by exchanging ,Reservation expiration alerts,✔︎Yes,✔︎Yes,✔︎Yes,✔︎Yes,✔︎Yes,✔︎Yes
*** This article was originally written in Japanese by Yuki Chiba (@batchicchi).
